No More Paddle Interaction..........................Mike Laumer

While working on the FLASH! Integer BASIC Compiler I ran into a nasty little problem because the compiled code ran too fast!   That's right, too fast.  The old problem with reading the game paddles too soon after one another rose to byte (punny huh!) me once again.

Basically the game paddle problem is that they are read with a variable time delay loop.  Because one paddle may read significantly faster than another, and the paddles have only one trigger to fire all four of the paddles, you might process the data fast enough to be ready to read the next paddle before it has finished its previous time delay.  This problem is real and occurs in many of the game programs to be found on the Apple.  Even Raster Blaster has the problem in its jittery ball release thrust adjuster.

In the example below paddle 0 and 1 are triggered by the $C070 paddle I/O trigger address.  But because paddle 0 has a smaller value, it finishes before paddle 1.  If you read one paddle after another with little other processing then one paddle seems to affect the value of the other one.  Many programmers have shown this problem to their dealer thinking that they have found a new bug in the Apple but the only problem (if one exists) is the lack of independent paddle triggers for each of the four paddles.

The problem appears if you use the following BASIC program and play with the paddle adjustments.  Turn paddle 1 to the middle of its scale and paddle 0 to the low end of its scale and you will see changing paddle 0 affects the value read for paddle 1.  You will find that paddle 1 will vary by 20-40 counts without even touching it.

   10 PRINT PDL(0),PDL(1) : GOTO 10


      +-------+
     -|       |-----------------     paddle 0

      +---------------+
     -|               |----------    paddle 1
     ^                ^
     :                : paddle expires
     :
     paddles are triggered at this time


So what can be done about the problem?  What I did is design a routine that reads the paddle without triggering it and waits for the paddle to shut off.  This is easily done by calling the monitor paddle read routine at $FB21, skipping the trigger instruction at $FB1E.  This takes care of much of the problem, but I still found it necessary to add a tiny delay loop before triggering the paddle.  The extra delay is probably due to the remaining charge in the internal capacitor in the timer chip.

The assembly language routine which follows is basically what I added to the FLASH! compiler runtime package to take care of its being too fast for its own good!  This explains 14 of the 36,000 bytes of object code in the FLASH! Compiler system.  There is also a DEMO program which reads both paddles and displays the values in hexadecimal so you can test the routine.
